-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sql: fix another buglet with tenant settings #109118
Conversation
It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR? 🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading this correctly, the bug here is that the crdb_internal.cluster_settings table was returning the name which was then being used in a join against the underlying systems table where the join actually has to happen on the setting_key.
If we wanted to add a test in this PR, I suppose we could make a test that registers a new setting that won't be in production builds and then write the test against that.
But, given that you seem to be iterating through test failures from the real-world case, we do know we have test coverage so perhaps we don't need to duplicate it.
This (hidden) bug was left over from cockroachdb#108902. There is no visible negative effect to this bug being present until setting aliases are effectively introduced, which hasn't happened yet. The code modified here is already properly exercised by logic tests. Release note: None
27ff4a5
to
b5a7b75
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm reading this correctly, the bug here is that the crdb_internal.cluster_settings table was returning the name which was then being used in a join against the underlying systems table where the join actually has to happen on the setting_key.
Yes.
given that you seem to be iterating through test failures from the real-world case, we do know we have test coverage so perhaps we don't need to duplicate it.
Correct
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @yuzefovich)
TFYR! bors r=stevendanna |
Build succeeded: |
This (hidden) bug was left over from #108902.
There is no visible negative effect to this bug being present until setting aliases are effectively introduced, which hasn't happened yet.
The code modified here is already properly exercised by logic tests.
Also, this is exercised by #109077 and #109074 and the CI in those PRs readily fail without this fix.
Epic: CRDB-27642